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0.  iGi rodyc £ign 

The  formal  basis  for  data  abstractions  began  with  their 
implementation  in  SIMULA  classes  [Dahl  e£  al*  197C],  and  Hoare's 
correctness-based  definition  [Hoare  19723  that  has  now  become 
known  as  the  "abstract  model"  approach,  refined  into  a program- 
proving  method  by  the  Alphard  group  CWulf  19763*  The 

"pure  algebraic"  approach  [ADJ  1978,  Guttag  1977,  Zilles  19753 
avoids  Loth  assertion-based  correctness  and  Implementation. 
Algebraic  axioms  may  themselves  be  used  as  rewriting  rules  to 
execute  trial  expressions  from  a data  type.  The  OBJ  CGoguen  and 
Tardo  19793  and  AFflR*  [Musser  19793  systems  use  this  idea  to 
make  specifications  "executable"  without  a conventional  program 
doing  the  computations.  In  these  systems  there  is  no  data* 
abstraction  programming  language,  only  a specification  language 
in  which  sample  terms  can  be  evaluated  by  symbolic  methods. 

Our  bias  is  toward  practical  use  of  abstractions,  as 
implemented  in  the  programming  language  SIMPL-O.  This  view 
probably  began  with  the  MIT  CLU  abstraction  project  CLiskov 
1976],  However,  a data-abstract ion  language  by  itself  faces  the 
problem  of  communicating  what  the  implementations  mean.  The 
language  nicely  gives  the  sZQlix  of  the  abstract  objects,  but 
their  semantics  must  be  conveyed  by  commentary  or  by  reading  the 
code.  The  former  is  unreliable,  and  the  latter  violates  the  very 
reason  for  encapsulating  abstractions  in  the  first  place.  Also, 
without  an  independent  expression  of  the  Intended  meaning,  we  are 
unable  to  judge  mechanically  the  success  of  the  implementing 
code.  we  thus  decided  that  the  usefulness  of  SIMPL-D  would  be 
enhanced  by  the  addition  of  specifications  in  a machine- 
processable  form.  The  bias  toward  practical  programming  remains, 
however,  so  we  decided  to  keep  away  from  correctness  ideas  in 
favor  of  testing  ideas.  Our  plan  is  to  use  algebraic-equation 
specifications,  and  to  test  whether  or  not  implementing  code 
meets  them . 
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An  immediate  difficulty  Is  that  such  a view  has  no 
theoretical  unde rp inn 1ng--t he  pur e~a l gebr a i c approach  does  not 
consider  Independent  iapleaentat  1 on  In  a programing  language* 
and  the  ab s t rac t-aode l approach  Is  Intertwined  with  correctness 
aethods.  we  aust  develop  definitions  appropriate  to  our 
situation,  definitions  In  which  the  iapleaentatlon  is  priaary* 
and  "correctness"  is  an  idea  that  a huaan  being  has.  unconnected 
with  proof  fornalisa.  The  resulting  definition  can  be  viewed  as 
that  of  Hoare*  with  the  assert lon-cor rect ness  reaoved.  We 
consider  it  a unification  of  the  algebraic  and  abstract~aodel 
approaches*  but  froa  the  algebraic  side*  unlike  the  effort  of 
[Flon  and  Hisra  19793. 

This  report  describes  the  abstraction  prograaaing  language 
SI^PL-0  (Section  1);  defines  the  aeaning  of  "correct 
iapleaentatlon"  and  "specification  by  axioas"  (Section  2);  gives 
language  and  compiler  extensions  needed  to  support  testing  the 
consistency  of  axioas  and  code  (defining  OAISTS*  Section  3);  and* 
explores  the  significance  of  successful  tests  (Section  4). 
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SIWPL-D  is  a «f*fc#r  of  the  S1WPL  family  of  programming 
languages  CBasili  1976]  with  features  that  permit  the  declaration 
of  abstract  data  types.  This  section  first  describes  the  basic 
features  that  are  coiwon  to  several  members  of  the  SIMPL  faafly 
of  languages  and  then  discusses  the  features  that  are  unique  to 
SIMPl-0. 

SIMPl-D  shares  the  following  language  features  with  soae  of 
the  other  languages  in  the  SlwPL  faaily. 

1.  A program  is  a series  of  global  variable  declarations 
followea  by  a series  of  procedure  declarations.  One  procedure  is 
designated  as  the  starting  point  of  execution  by  including  its 
name  in  a START  command  as  the  last  line  of  a prograa. 

2.  There  is  no  block  structure  and  procedures  aay  not  be 
nested.  Each  procedure  aay  access  global  variables*  foraal 
parameters*  and  local  variables. 

3.  Procedures  aay  be  recursive.  Procedures  aay  not  be  passed 
as  parameters;  scalar  data  objects  aay  be  passed  by  value  or 
reference  and  aggregates  are  passed  by  reference.  Only  scalar 
objects  may  be  returned  as  values. 

4.  The  language  is  strongly  typed  with  the  basic  data  types 
integer*  character*  and  string.  Explicit  conversion  routines 
exist  to  coerce  values  from  one  of  the  basic  types  to  another. 
Zero  is  false  and  nonzero  is  true  in  contexts  requiring  boolean 
values  te.g.*  IF  statements).  The  usual  arithmetic*  relational* 
and  logical  operators  are  available.  In  addition*  there  are 
string  operators  for  concatenation  and  substring  selection. 

5.  The  only  intrinsic  type  generator  Is  the  array  of  single 
dimension  with  comp i le-t 1 me  determinable  bounds.  The  lower  bound 
for  arrays  is  fixed  at  zero. 

6.  The  statements  of  the  language  include  assignment*  IF* 
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CASE,  WHILE,  EXIT,  CALL,  and  RETURN.  There  ere  primitives  for 
stream  and  record  Input  and  output. 

7.  Separate  compilation  is  supported  using  ENTRY  and  ExTernal 
dec larations. 

The  primary  new  feature  of  SIHPL-D  is  the  CLASS.  CLASS 
declarations  define  new  types  uhich  may  subsequently  be  used  in 
other  declarations.  The  interior  of  a CLASS  is  a series  of 
variable  declarations  (the  representation)  followed  by  a series 
of  procedure  declarations  (the  body).  Either  the  repre sentat ion 
(by  declaring  a CLASS  to  be  CLEAR)  or  the  procedures  of  the  body 
(by  listing  them  in  the  CLASS  heading)  may  be  visible  outside  a 
CLASS  declaration.  A CLASS  with  no  procedures  associated  with  it 
and  whose  representation  is  available  to  users  is  simply  a 
record.  Conversely,  a CLASS  whose  representation  can  only  be 
accessed  by  users  through  the  procedures  of  the  CLASS  defines  an 
abstract  data  type. 

Users  generally  view  CLASS  objects  as  indivisible  entities. 
Inside  the  CLASS,  these  objects  may  be  viewed  as  a sequence  of 
declarations  of  more  primitive  objects.  The  primitive  objects 
may  be  declared  with  one  of  the  storage  attributes  UNIQUE  or 

shared. 


CLASS  Stack  = Push,  Pop,  Top,  Empty 


/*  representat ion  «/ 


SHARED  INT  ARRAY  Values(IQOO) 
SHARED  INT  ARRAY  NeHtvalue(100Q) 
SHARED  INT  Avail 
UNIQUE  INT  Stacktop 


/*  body  */ 


ENDCLASS 
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UNIQUE  components  of  a CLASS  are  allocated  each  time  a CLASS 
object  is  created,  SHARED  components  of  a CLASS  are  allocated 
only  once  (no  matter  how  many  CLASS  objects  are  created)  at 
program  initiation  and  are  common  to  all  objects  of  the  same 
type.  In  the  example  above,  each  Stack  object  consists  of  a 
single  integer  component,  Stacktop,  The  value  of  a Stack  object 
might  be  constructed  by  using  its  Stacktop  component  as  a 
reference  to  a linked  list  whose  links  are  stored  in  Nextvalue* 
The  links  in  Nextvalue  reference  positions  in  the  integer  array 
Values  that  contain  the  values  currently  the  list*  All  Stack 
objects  share  the  common  space  for  values  a”d  links;  no  Stack 
object  need  overflow  until  the  storage  requirements  for  all  Stack 
objects  exceeds  1000  values. 

The  body  of  a CLASS  is  a series  of  procedure  and  function 
dec l a ra t i ons . If  one  of  these  routines  accepts  a formal 
parameter  of  the  CLASS  being  defined,  the  body  of  the  routine  may 
access  the  UNIQUE  components  of  the  formal  using  a period 
notation  similar  to  that  of  Pascal  or  PL/I*  Since  only  a single 
cop  of  the  SHARED  components  exist,  no  similar  qualification  is 
necessary  to  access  them.  Continuing  our  example  from  above,  we 
might  define  Pop  as  follows: 

Stack  FUNC  Pop  (Stack  S) 

INT  Temp 

IF  Empty(S) 

THEN 

WRITE('**»  underflow  ***') 

ABORT 

END 


/*  put  location  of  previous  value  in  Stacktop 
Temp  :=  S. Stacktop 
S. stacktop  : * Neat va l ue (Temp > 


/*  update  chain 
Nextvalue (Temp ) 
Avail  :*  Temp 


RETURN(S) 


of 


available 

Avail 


locations  */ 
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A list  of  integer  parameters  to  the  CLASS  may  be  used  to 
control  the  sizes  of  the  UNIQUE  components  of  the  representat ion. 
These  parameters  are  themselves  treated  as  UNIQUE  components  of 
an  object,  but  their  values  may  only  be  altered  by  the  assignment 
of  an  object  to  the  entire  object  of  which  they  are  a component. 

CLASS  Stack (Stacksize)  * Push.  Pop.  Top.  Empty 

UNIQUE  INT  ARRAY  V a l ues  ( S t ac  k s i ice  ) 

UNIQUE  INT  Stacktop 
• 

ENDCLASS 

The  appearance  of  the  reserved  word  ASSI6N  in  the  operation 
list  enables  the  SIMPL  assignment  operation  (:*>  to  be  applied  to 
objects  of  this  CLASS  type.  As  is  the  case  with  objects  having 
primitive  SIMPL  types,  applying  the  assignment  operation  to  CLASS 
objects  results  in  the  value  of  the  right  operand  being  copied  to 
the  location  of  the  left  operand.  If  the  run-time  value  of  the 
right  operand  is  too  large  to  store  in  the  left  operand,  an  error 
results.  Assignment  is  not  allowed  for  classes  containing  SHARED 
components  because  of  possible  side  effects  on  shared  components. 

Two  nameless  procedures  are  available  to  provide  automatic 
ini tialization  of  UNIQUE  and  SHARED  data  of  a CLASS.  SHARED 
components  are  initialized  once  at  program  initiation  through  an 
implicit  call  to  the  appropriate  nameless  procedure.  UNIQUE 
objects  are  initialized  at  the  time  of  their  creation  (either 
program  initiation  for  globals  or  procedure  invocation  for 
locals)  through  an  implicit  call  to  the  appropriate  nameless 
procedure.  The  CLASS  defining  the  type  Stack  above  might  contain 
such  a procedure  to  initialize  Stack  objects  to  be  empty. 

INIT  UNIQUE  PROC  (Stack  S) 

S.StackTop  :=  -1 

Declarations  establish  the  types  and  sizes  of  variables,  but 
the  size  of  a variable  is  not  part  of  its  type.  Size  parameters 


cannot  oe  specified  in  the  declarations  of  foraal  paraaeter s or 
function  results;  th.se  objects  have  sizes  that  cannot  be 
determined  until  run  time.  The  size  values  of  foraal  paraaeters 
are  those  of  the  corresponding  actual  paraaeters.  The  size  value 
of  a function  result  is  that  of  the  expression  appearing  in  the 
return  statement.  Thus  objects  of  arbitrary  sizes  can  be  passed 
to,  and  returned  from,  routines.  In  the  following  example.  Si 
and  S2. are  variables  with  the  same  type  (Stack),  but  different 
sizes  (5O  and  5 respectively). 

Stack ( SO)  SI 
Stack(5)  S2 
• 
a 

SI  :=  Pop ( S2  > 

The  following  is  a full  definition  of  the  data  type  "bounded" 
Stack  and  its  use  in  a SIHPL-P  program.  The  operations  available 
on  Stack  objects  are  listed  in  the  CLASS  heading;  the  code 
implementing  these  operations  (except  for  ASSIGN  which  is  system- 
defined)  is  found  in  the  CLASS  body.  Push  places  a new  value  on 
top  of  a Stack  object  and  returns  the  object  as  the  result  of  the 
operation.  Attempts  to  place  a new  value  on  a full  Stack  object 
are  ignored.  Pop  removes  a value  from  a nonempty  Stack  object 
and  has  no  affect  on  eapty  Stack  objects.  Top  returns  the  value 
on  top  of  a Stack  object,  but  does  not  remove  the  value  froa  the 
object.  Top  returns  Undefined  (In  this  example,  Undefined  is  0 
as  a result  of  the  macro  definitions  controlling  the 
representation.)  if  it  is  applied  to  an  eapty  Stack  object. 
NewStack  returns  as  its  value  an  eapty  Stack  object.  Depth  can 
be  used  to  discover  the  number  of  values  in  a Stack  object  and 
Limit  gives  the  upper  bound  on  the  number  of  values  that  can  be 
placed  in  any  Stack  object.  An  array  of  EltType  (defined  as 
integer  by  a macro)  values  and  an  index  of  the  last  value, 
StackTop,  fora  the  representation  for  Stack  objects.  Each  time  a 
Stack  object  is  bound  to  storage,  space  is  reserved  for  the  array 
and  integer  index. 
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CLASS  Stack  = Pusht  Pop,  Top,  Eapty,  NewStack, 
StackEqual,  Depth,  liait»  ASSIGN 


/*  itcro  definitions  to  control  representation  */ 
DEFINE  EltType  * INT  ' 

DEFINE  Undefined  = ' 0 ' 

DEFINE  StackSize  * '20' 


/*  representation  *! 

UNIQUE  EltTvpe  ARRAY  V a l u e s < S t a c k S 1 z e ) /*  0 . . S tac k S 1 ze- 1 */ 
UNIQUE  INT  StackTop 


/*  body  containing  operation  definitions  */ 


Stack  FUNC  NewStack 
Stack  Result 
Re sul t . S t ac k t op  :*  -t 
RETURNlResult ) 


Stack  FUNC  PushiStack  S,  EltType  Elt) 

Stack  Result 

IF  S.StackTop  ♦ 1 = StackSize 
THEN 

RETURN(S)  /*  return  stack  unchanged  */ 

END 

Result  :*  S 

Re su l t • S t ac kTop  :*  R esu l t * S tac k Top  ♦ 1 
Re  su  1 1 . Va  lue  s <«e su  1 1 . S t a ck  Top  > : = Elt 
RETURNlResult  ) 


Stack  FUNC  PoplStack  S> 

Stack  Result 
IF  E«|ty(S) 

RETURN(S) 

END 

Result  : = S 

Re sul t • S t ac kTop  : = Resu l t . S tac kTop  - 1 
RE  TURN l Re  su 1 1 ) 


EltType  FUNC  Top  (Stack  S) 
lr  Ea^tylS) 

RETURN (Undef  ined) 

END 

RETURN(S.Values(S.StackTop>> 


Bool  FUNC  Empt  y (Stack  S) 
rE TORN (S • St ackTop  * -1 ) 
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Bool  FUNC  StackEqual (Stack  P,  Stack  0) 

1 N 7 I 

IF  Depth (P)  = Depth (Q ) 

THEN 

I :*  Depth(P) 

WHILE  I > 0 DO  /*  compare  alt  eleaents  */ 
IF  P .Values  (I ) <>  Q.Values(I) 

THEN 

RETURN(False) 

END 

I : = I - 1 
END 

RETURN(True> 

END 

RETURN(False) 


1NT  FUNC  Depth (S  tack  S) 

RETURNtS.StackTop  ♦ 1) 


1NT  FUNC  Liait 

RETURN(StackSize) 


ENDCLASS  /*  end  of  declaration  of  CLASS  Stack  */ 


PROC  P /*  progr j«  using  variables  of  type  Stack  •/ 


INT  1 

Stack  S 

S :«  NewStack 


/*  read  and  add  values  to  S */ 

WHILE  .NOT.  EOI  DO  /*  EOI  Is  end-of-lnput  */ 

read  (i ) 

S :=  Pus h ( s 1 1 ) 

END 


/•  write  and  reaove  values  from  S */ 
WHILE  •not.  Eapty(s)  DO 
WRlTE(top<S),SkIP) 

S :*  Pop ( S ) 

END 


START  P 
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A language  like  SIWPL-D  supporting  data  abstraction  defines 
abstractions  using  a collection  of  Its  primitive  objects  and 
procedures.  Because  the  language  has  a formal  semantic 
definition,  these  elements  have  an  Intuitive  meaning,  roughly 
that  the  primitive  objects  correspond  to  some  abstract  objects 
strings  over  some  finite  alphabet,  or  natural  numbers), 
and  the  procedures  to  mappings  among  the  abstract  objects.  An 
implementation  of  a data  abstraction  therefore  has  meaning, 
constructed  from  the  language-definition  meanings  of  the  objects 
and  procedures  used.  The  question  is  whether  this  meaning 
corresponds  to  what  a human  being  had  in  mind  for  the  abstract 
object,  we  begin  by  framing  a simple  definition  that  captures 
this  i dea  . 

Suppose  that  the  programming  language  has  but  a single 
primitive  type,  whose  meaning  is  a set  of  abstract  objects  D . 
(In  the  usual  "structured  programming"  treatment  [Linger  jj: 

19793  the  objects  D are  the  integers,  the  meanings  of  program 
variables  of  type  int.)  The  meanings  of  procedures  are  mappings 
of  cross  products  of  p into  cross  products  of  0 . (To  obtain 
a tuple  of  outputs  it  may  be  necessary  to  resort  to  "output 
parameters";  in  a language  like  ALGOL  68  such  objects  may  be 
function  values  directly.)  The  semantics  of  a programming 
language  can  be  thought  of  as  the  definition  of  the  meaning 
mapping:  an  assignment  of  the  abstract  function  to  the  procedure 

fragment  of  the  language  syntax.  Because  it  is  important  to  know 
when  such  an  abstract  function  is  under  discussion,  we  name  them 
with  a peculiar  notation  due  to  Kleene:  fSe  meaning  function  of 
the  program  fragment  P is  written  CP3  • Thus  for  a function 
procedure  P with  two  parameters, 

tP3:  D x o “““>  0 

is  the  meaning.  The  semantic  definition  of  the  language 
establishes  the  detailed  correspondence  between  P and  tp3  . 
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'*  e sa  y that  P SQBByiSS  tP3  • The  crucial  point  is  that  by 
using  the  language  definition  we  can  discuss  not  P r but  [P3  , 
and  thus  deal  only  with  abstract,  intuitive,  meaning  objects,  not 
concrete,  syntactic  ones. 

I n this  discussion  we  have  not  committed  to  whether  or  not 
the  semantic  domain  D is  finite*  In  any  actual  implementation 
it  must  be,  but  there  are  good  reasons  to  take  it  to  be  in 
principle  unbounded  as  Turing  did.  In  fact,  data  abstraction 
itself  can  be  used  to  bridge  the  gap,  because  potentially 
unlimited  objects  like  strings  can  be  implemented  as  character 
arrays  using  dynamic  memory  allocation,  the  ultimate  limitation 
being  only  the  exhaustion  of  virtual  memory* 

The  domain  of  a data  abstraction  is  like  0 , except  that  it 
does  not  correspond  to  any  built-in  programming-language  objects* 
For  implicity  let  it  be  a single  kind  of  abstract  objects,  say 
the  et  A . Let  the  objects  D play  the  dual  role  of  meaning 
for  programming  language  primitive  objects,  and  a second  abstract 
domain  for  opposition  to  A , The  abstract  operations  are 
mappings  from  cross  products  of  A and  D into  A or  D • 

(The  complication  of  permitting  cross  product  ranges  here  adds 
nothing.)  The  abstract  operations  also  have  no  built-in  language 
procedures.  The  data  abstraction  features  of  the  language 
provide  a means  of  defining  language-to-abstraction 
correspondences*  In  the  simple  case  we  are  considering,  the 
abstract  objects  A are  made  to  correspond  to  tuples  from  0 , 
and  aostract  operations  to  procedures  mapping  these  tuples*  That 
is,  the  programmer  implementing  an  abstraction  mentally 
establishes  a £SB££S£DifiiiSD  capping  R , 

k 

R : 0 > A (onto) 

carrying  the  built-in  meanings  to  the  desired  ones*  This  mapping 
is  reflected  in  the  language  by  an  ordered  collection  of 
declarations.  In  SIPPL-D  these  are  the  declarations  of  a CLASS 
in  order,  so  that 
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CLASS  C 


• • • 


UNIQUE  INT  x , y , z 


would  establish  the  representation  as  having  a domain  of  triples 
of  (abstract)  integers.  Note  that  in  this  view  the 
implementation  syntax  gjfingj  the  abstraction  domain,  so  that  no 
abstract  syntax  is  needed  in  addition;  however,  the  object  such  a 
triple  is  to  represent  is  entirely  unspecified. 

Similarly,  the  data  abstraction  facilities  of  the  language 
allow  definition  of  language  procedures  that  correspond  to  the 
abstract  operations,  and  the  language  syntax  defines  the  abstract 
domains  and  ranges.  For  example,  in  S1MPL-D  if  there  were  just 
one  operation  carrying  a pair  of  abstract  objects  into  the 
l anguage-pr im i t i ve  objects,  we  would  have 

CLASS  C * op 

UNIQUE  INT  x,  y,  z 

INT  FUNC  op ( C a,  C b) 

• • • 

in  which  the  CLASS  name  C is  used  to  stand  in  for  the 
representing  triple  in  the  parameter  list.  Again  the  syntax 
carries  over  to  the  abstraction,  but  there  is  no  meaning  given 
there* 

Because  of  the  way  this  syntax  is  constructed,  it  is 
impossible  to  write  a syntactically  correct  SINPL-O  program  that 
does  not  implement  S8BS  abstraction,  so  we  make  this  the  first 
definition:  an  imgltfgQigi jgrj  of  a data  abstraction  is  just  a 

representat ion  and  a collection  of  function  dec  larat ions.  The 
implementation  defines  the  syntax  of  the  abstract  object  and 
abstract  operations. 

Once  programming  language  code  has  been  filled  in  for  the 
functions  declared  in  an  implementation  of  an  abstraction,  one 
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meaning  js  defined,  by  that  implementation  through  the  language's 
semantic  definition.  But  the  programmer  is  supposed  to  have  an 
abstract  aeaning  in  aind  a e£ifi£i»  «°  ««  not*  define  what  it  means 
for  this  intuitive  idea  to  be  captured  by  the  code.  It  is  clear 
that  we  should  assert  that  the  given  prog  ram-induced  meaning  is 
the  one  intended.  For  example,  in  the  case  of  a representat ion 

R:  D x 0 > A 

(that  is,  pairs),  and  an  abstract  operation 
f:  A x 0 — ->  A 

implemented  by  a procedure  P (in  SINPL-0  it  would  appear  as 

CLASS  A = P 

UNIQUE  INT  x,  y 

A fUNC  P ( A u,  INT  2) 

• • • 

if  the  primitive  type  0 is  INT),  the  code  represented  by  the 
body  of  P defines  tPD  as  a mapping 

2 2 
CPD:  0 x 0 > 0 . 

Correctness  of  the  implementation  then  amounts  to  the  assertion 
that  the  following  diagram  commutes: 

f 

A a o *-  * > s 


0 x 0 > D 

we  Call  this  an  iiBitltolil Joo  diifltil  of  P • In  general,  the 
implementation  is  tgrrgtt  iff  e«ch  of  its  functions  satisfies 
this  condition;  namely  that  any  representat ion  tuple*  carried 
into  the  abstract  A by  R and  mapped  by  the  abstract 
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operation*  produces  the  sa«e  (abstract)  value  as  capping  that 
representation  tuple  by  the  implementing  procedure*  then 
representing  the  result*  In  symbols*  for  the  example* 

2 

correctness  requires  that  for  any  pair  (s*t)  € 0 * and  any  a € 

D . 

f(R(s*t)«  a)  = R([P](s*  t*  a))  • 

(In  the  special  case  that  D itself  is  a part  of  the  abstract 
domain,  we  require  that  the  identity  representation  be  used*  and 
we  do  not  show  it  in  the  implementat ion  diagram*) 

we  emphasize  again  that  this  definition  is  framed  entirely  in 
the  abstractions  D * A * f * and  tPD  • Of  course*  there  is 
a correspondence  with  the  language  object  P through  CP)  * and 
the  tuples  from  D have  language  correspondents*  but  these  do 
not  occur  in  the  definition.  Note  also  that  the  abstract  syntax 
comes  entirety  from  the  implementation  syntax--lt  has  no 
independent  existence*  and  the  abstract  meaning  is  so  far 
confined  to  the  mental  processes  of  human  beings* 

Side  effects  of  the  implementation  can  also  be  discussed  in 
this  context.  Intuitively*  the  implementation  has  side  effects 
if  executing  its  procedures  not  only  yields  their  returned 
values,  but  furthermore  alters  the  state  of  some  internal 
storage*  In  SIHPL-D,  "internal  storage"  is  the  SHARED  and  UNIQUE 
data  of  a CLASS,  which  we  are  treating  as  a tuple  of  objects  from 
the  set  D • In  framing  a definition  of  "side  effect,"  should 
all  storage  within  the  implementation  be  in  the  domain  of  the 
intuitive  representation  function*  or  should  some  of  it  (say  the 
SHARED  part)  be  in  a hidden*  "side-ef feet"  store?  We  choose  to 
include  everything  in  the  r epresentat ion  domain*  because  it 
preserves  the  intuition  that  this  mapping  captures  the  entire 
correspondence  between  implementation  objects  and  abstract  ones* 
and  because  the  resulting  mathematics  is  cleaner*  (As  an  example 
of  the  latter*  the  Implementation  diagrams  explicitly  show  all 
the  relevant  data*) 
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Intuitively,  there  is  a side  effect  if  storage  is  different 
after  a procedure  has  been  invoked  than  it  was  before*  To 
capture  the  idea  of  a time  history,  we  consider  an  £jitQd£d 
l!!Ei22£Di4ii2D  Sjiafl£i!  that  displays  a succession  of 
implementation  procedure  invocations*  For  example,  for  the 
operation  f:  A x D — > A above,  the  implementing  P night  be 
used  on  its  own  output,  leading  to  the  diagram: 

f f 

A x D > A x D > A 


R 


2 


D 


X 


m 


2 

D x 


D 


m 
— > 


v 

D 


(In  the  diagram  we  omit  not  only  the  identity  nap  D D , but 

2 

the  internal  R:  D — > A .) 

Formally,  there  is  a jjdj  flistl  in  a sequence  of 
implementation  procedures  iff  an  extended  implementation  diagram 
exists  with  the  following  property:  Starting  at  the  upper  left, 
some  abstract  x is  the  image  under  the  representation  R of 
the  set  (of  tuples) 


E * Id  | R(d)  * a>  • 

Some  x € E is  carried  along  the  bottom  of  the  diagram  back 

0 

into  t by  the  imp l ement at  ion  procedures  in  composition* 

However,  there  exists  a y € E that  is  carried  along  the  bottom 
of  the  diagram  to  y * distinct  las  a tuple)  from  y • A side 
effect  is  fesnggs^gQl  iff  every  such  y'  8 E • 

The  intuition  behind  this  definition  Hollowing  CHoare  19723) 
is  that  "side  effect"  is  meaningless  unless  the  extended 
implementation  diagram  returns  to  a representation  of  the  same 
abstract  object.  That  is*  the  notion  depends  not  just  on  the 
implementing  code,  but  on  the  representat Ion  that  the  programmer 
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had  In  aind.  So  long  as  extended  iapleaentation  diagrams  produce 
sequences  of  representations  of  dillC£SCi  abstract  objects,  the 
effect  is  primary,  not  "side**,  When  there  is  a return  to  the 
same  a ra  t o e t • but  with  a different  representing  tuple,  a 

side  ef  ct  has  occurred.  Benevolence  aeans  that  such  changes  do 
not  aatter — the  representation  aapping  washes  thea  out*  The 
somewhat  surprising  thing  is  that  in  any  abstraction  correctly 
implemented  by  given  code,  any  side  effects  ay$J  be  benevolent, 
hrowing  an  interesting  highlight  on  Hoare's  contention  that  the 
terms  are  alaost  cont radi ctory * For  suppose  that  a side  effect 
is  not  benevolent;  that  is,  for  soae  extended  iapleaentation 
diagram  a set  E of  iapleaentation  tuples  representing  the  saae 
abstract  object  is  aapped  partly  into  itself,  and  partly  into 
representations  of  another  abstract  object.  Choosing  one 
representing  tuple  of  each  kind  at  the  lower  left  of  the  diagram, 
on  the  upper  (abstract)  path  they  lead  to  the  saae  object,  but  on 
the  lower  (iapleaentation)  path  they  do  not.  Hence  the 
implementation  cannot  be  correct, 

when  the  representation  aapping  is  1-1,  side  effects  are 
impossible  accor  i ng  to  this  definition.  There  are  no  classes  of 
representing  tuples  other  than  singletons,  and  so  the  benevolent 
confusion  within  such  a class  cannot  occur.  The  usual  notion  of 
a “side  effect**  that  is  QgJ  benevolent  is  formally  just  an 
incorrect  i ap l eaen t a t in- - f the  object  y that  is  sent  to  y' 
t y by  the  code  is  one  that  displays  a side  effect,  and 
procedure  Q misbehaves  ■ /'  where  it  would  not  have 

misbehaved  on  y , there.,  possible  cases  according  to  the 

formal  definition: 

(1)  The  si<Je  effect  in  the  extended  diagram  prior  to  the 
pplication  of  Q is  benevolent;  that  is,  the  representat ion 

does  n t distinguish  between  y and  y ' • Then  a itself  is 
incorrect , 

(2)  The  side  effect  is  not  benovelent;  that  Is,  the 
representation  maps  y and  y ' onto  different  abstract  objects. 
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Then  somewhere  in  the  extended  diagram  prior  to  the  application 
of  Q there  is  an  error  in  the  implementation. 


The  situation  regarding  side  eifeets  can  be  summarized  as 
follo.s:  correctness  of  an  implementation  (as  defined  by 

commuting  implementation  oiagrams  for  all  its  procedures) 
guarantees  that  all  extended  implementation  diagrams  will  also 
commute* 


According  to  the  definition  above*  the  implementation  fixes  a 
syntan— the  sets  of  objects*  and  the  names*  domains*  and  ranges 
of  operations*  This  syntax  is  called  the  2lfl2ilUI£  of  the 
abstraction*  as  in  [ADJ  19763*  We  now  investigate  the  structure 
of  all  abstractions  with  a fixed  signature*  For  any  two 


abstractions  A 


homgmorghijm  h: 


and  A with  the  same  signature*  a 
2 

A -->  A satisfies  equations  such  as 
1 2 


h(f(x*y>)  = f(h(«)*h(y)> 


for  all 


in  the  domain  of 


in  A^  « for  all  operations 


f of  the  signature  (with  appropriate  argument  l i sts--here  shown 
as  pairs).  We  use  the  same  name  for  the  operation  f in  both 
ab s t rac t i ons.  An  onto  homomorphism  is  an  SCiffilfibijB'  • 1“1 
epimorphism  is  an  ilfimgfBb jj§.  We  say  that  A^  is  a homomorphic 

(epimorphic*  isomorphic)  imggg  of  A^  (under  h )•  Identifying 

all  isomorphic  abstractions*  define  a partial  order  by  A^  £ A ^ 

iff  A ^ is  an  epimorphic  image  of  A^  • The  trivial  abstraction 

. I containing  one  element  mapped  to  itself  by  all  operations  is 
the  least  element  in  this  partial  ordering* 

When  a person  sets  out  to  implement  an  intuitive  abstraction 
in  a programming  language  like  SIPPL-D,  he  proceeds  by  first 
choosing  a representation*  then  writing  code  to  manipulate  its 
tuples  appropriately.  However*  given  a SINPL-D  CLASS  definition* 
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it  may  implement  certain  abstractions  correctly*  whatever  the 
programmer  had  in  mind.  One  candidate  is  always  the  trivial 
abstraction.  in  that  case*  whatever  the  prograaaer  writes  for 
code  is  correct  if  the  procedures  do  not  abort  or  fail  to 
ter»indte,  because  every  tuple  is  mapped  to  the  saae  abstract 
point.  If  the  trivial  abstraction  is  not  what  the  prograaaer  had 
in  mind,  it  is  tempting  to  say  that  the  representation  is 
incorrect*  but  according  to  our  definition  that  distinction 
cannot  be  made — the  range  of  the  representation  mapping  is 
entirely  intuitive.  Another  intuitive  abstraction  always 
correctly  implemented  by  any  code  is  one  that  airrors  the 
i mp lemen t a t ion  Itself.  That  is*  the  representation  is  an 
identity  map*  and  the  intuitive  operation  cor  responding  to 
procedure  P is  just  CP]  . In  this  case  the  top  and  bottoa 
lines  in  the  implementation  diagraa  are  identical*  so  it 
necessarily  commutes*  (Here  even  the  possible  failures  of 
termination  in  the  code  are  of  no  consequence • ) 

Between  the  trivial  abstraction  and  the  one  that  airrors  the 
implementation*  all  elements  of  the  partial  ordering  are 
correctly  implemented*  because  given  any  A that  is  an  image  of 
the  mirror-image  abstraction  under  a homomorphism  h*  h itself  is 
a representation  onto  A that  forces  the  appropriate  diagrams  to 
commute.  It  is  likely  that  the  successful  programmer  had  some 
element  of  this  partial  order  in  mind,  but  probably  not  the 
extreme  elements.  Insofar  as  the  implementation  takes  advantage 
of  the  full  detail  of  the  representing  tuples*  the  abstractions 
it  correctly  implements  are  likely  to  cluster  near  the 
implementation-mirror  end  of  the  order;  if  the  representing 
structure  is  largely  Ignored*  near  the  trivial  end. 

The  definition  above  captures  implementation  of  an  f BtifiCi 
abstract  data  type.  If  the  human  being  who  envisioned  the  type 
is  available  to  act  as  an  oracle*  and  can  perform  the 
representation  function*  then  the  definition  can  be  used  directly 
to  perform  tests  of  the  imp lementat ion.  The  person  chooses  a 
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representing  tuple*  maps  it  to  the  corresponding  abstract  object* 
performs  abstract  operations  and  records  the  result*  The 
implementing  program  is  given  the  same  representing  tuple  and 
produces  another  such  tuple;  the  human  being  also  maps  this  to 
its  corresponding  abstraction  and  compares  it  with  the  recorded 
result.  Agreement  means  a successful  test.  This  process  cannot 
be  automated  without  some  form  of  specification  that  describes 
the  abstract  type  independent  of  the  implementation*  We  have 
chosen  algebraic  axioms  [Guttag  1977]  as  the  most  attractive  such 
specification  method*  The  exact  form  the  axioms  take  can  be  left 
open;  in  particular*  we  have  not  decided  the  several  questions  of 
(a)  whether  or  not  the  functions  involved  must  be  total  (and 
hence  the  fora  recursions  are  allowed  to  take)*  (b)  whether  or 
not  existential  quantifiers  will  be  allowed  as  well  as  universal 
quantifiers*  and  (c)  whether  of  not  "conditional"  cases  will  be 
allowed  in  the  axioms*  Our  testing  scheme  will  work  in  any 
combination  of  decisions  about  these  matters*  so  the  decisions 
can  be  deferred* 

whatever  fora  the  axioms  take*  they  are  a finite  collection 
of  relations  among  terms  constructed  from  abstract  functions* 
closed  by  quantifying  the  variables.  An  intuitive  abstraction 
iiliiliSi  a set  of  axioms  iff  each  is  true  in  the  natural 
interpretation  into  the  intuitive  domain  (in  the  technical  logic 
sense).  That  is*  the  intuitive  axiom  relation  holds  of  the 
intuitive  term  objects*  Given  any  point  in  the  partial  order  of 
abstractions  satisfying  a set  of  axioms*  points  below  it  in  the 
partial  order  also  satisfy  them*  because  the  epimorphism  that 
maps  downward  in  the  partial  order  commutes  with  all  the 
operations*  and  this  is  sufficient  to  show  that  the  axioms  are 
inherited,  we  report  more  results  on  the  relationship  between 
the  implemented  abstractions  and  the  specified  abstractions  in 
[Ardis  and  Hamlet  1979], 

Given  a S1MPL-0  CLASS  and  a set  of  axioms  written  in  terms  of 
its  operation  names*  there  are  thus  three  things  of  interest 
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within  the  partial  ordering  of  abstractions: 

(1)  The  abstraction  the  programmer  had  in  aind. 

(2)  The  set  of  abstractions  that  the  code  correctly 
implements. 

(3)  The  set  of  abstractions  that  satisfy  the  axioas. 

If  it  happens  that  (1)  is  somewhere  in  (2)  and  also  in  (3),  the 
programmer  can  be  said  to  have  succeeded.  (Howe  ve  r , ao  re  could 
be  demanded.  Soae  of  those  taking  the  a l gebra i c -ax i oa  approach 
often  require  that  (1)  correspond  to  the  initial  eleaent  of  (3). 
viewed  as  a category  TAOJ  19783.  We  do  not  insist  on  this 
additional  condition,  although  we  would  be  pleased  to  be  able  to 
detect  that  it  is  satisfied.)  There  are  aany  ways  for  the 
programmer  to  fail,  however.  Since  (1)  does  not  and  cannot 
appear  explicitly  in  the  S1PPL-D  text,  technically  we  can  only 
investigate  the  relationship  between  (2)  and  (3>.  However,  both 
code  and  axioas  are  huaan  attempts  to  capture  (1),  and  they  are 
sufficiently  different  that  we  aay  hope  their  relationship  will 
illuminate  their  conon  source,  even  though  it  is  not  foraally  in 
evidence. 

Testing  is  the  aechanisa  we  have  chosen  to  investigate  the 
relationship  between  axioas  and  code.  Test  points  in  the  fora  of 
implementation  tuples  can  be  inserted  in  the  axioms  viewed  as 
expressions  in  SIPPL-D.  This  amounts  to  associating  with  each 
axiom  its  extended  i mpleaentat  ion  diagram,  and  moving  across  the 
bottom  of  the  diagram.  Since  the  outermost  function  in  each 
axiom  is  equality,  and  since  the  representation  mapping  into  the 
Boolean  domain  <l£U£»  liisj)  is  likely  to  be  one-one,  we  can 
view  the  test  as  supplying  half  the  information  about 
commutativity  for  one  point. 

Let  us  suppose  that  such  a test  fails.  That  Is,  soae 
rep  re sentat ion  tuples  are  chosen*  the  appropriate  values  that 
occur  in  an  axiom  are  worked  out  (In  lapleaentat ion  tuples 
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djain),  and  the  resulting  value  represents  fjijj.  Then  if  the 
axiom  does  hold  for  the  intuitive  abstract  objects*  the 
implementation  must  be  incorrect  (in  the  technical  sense  above), 
and  its  failure  lies  in  one  or  more  of  the  procedures  whose  names 
appear  in  the  axiom.  Since  the  axiom  hot  s of  the  abstract 
objects*  the  test  point  oust  lead  around  the  upper  path  of  the 
extended  implementation  diagram  to  |ruj;  but*  the  lower  path 
leads  to  laiSfi.  This  can  occur  only  if  one  of  the  component 
implementation  diagrams  similarly  fails  to  commute.  It  is 
important  to  note  that  nothing  is  assumed  about  the  specification 
“capturing"  the  intuitive  abstraction  except  that  a single  a"io* 
is  true  of  it. 

There  is  an  exception  when  an  axiom  uses  existential 
quantification.  Then  the  additional  possibility  exists  that  the 
code  is  not  incorrect*  but  rather  the  data  points  used  are  so 
sparse  that  no  representation  of  the  needed  object  was  included. 
Furthermore*  an  existential  failure  is  over  a whole  set  of 
points,  and  not  for  a single  point*  thus  making  it  harder  to 
trace*  Perhaps  these  are  sufficient  reasons  to  avoid  existential 
quantifiers  in  axioms. 

Unfortunately*  a successful  test  gives  less  information:  if 
the  axioms  define  the  abstraction*  and  the  implementation 
satisfies  them  for  a point*  it  could  yet  happen  that  several  of 
the  implemented  funcions  are  not  correct  for  the  point*  but  in 
comoination  their  errors  cancel  each  other  to  make  the  test 
succeed.  The  case  of  an  existentially  quantified  axiom  is  again 
noteworthy:  the  existence  of  a tuple  that  satisfies  the  axiom 

may  be  illusory  if  the  procedures  implementing  the  operations  on 
it  are  incorrect.  We  do  not  expect  tests  to  establish  the 
correctness  of  the  i mplementat ion  * but  the  success  of  a test  when 
the  code  is  wrong  for  the  test  inputs  is  particularly  disturbing. 
This  difficulty  can  occur  even  with  exhaustive  testing*  and  even 
if  the  equality  function  of  the  abstraction  is  correctly 
implemented.  Intuitively*  it  arises  because  the  definition  of 
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correctness  (following  Hoare)  proceeds  function-by-function, 
white  the  a Igebrai c-equat  ion  specification  may  only  define  the 
operations  in  combination.  Of  course*  the  success  of  an  axiom 
involving  only  one  operation*  under  exhaustive  testing  and 
assuming  a correct  implementation  of  equality*  is  definitive. 

we  do  not  contemplate  exhaustive  testing*  but  we  do  want  to 
know  that  an  incorrect  implementation  gg£§£§2SS  a test  point  that 
exposes  its  error.  with  the  coverage  criteria  described  in 
Section  4*  we  can  then  measure  the  liklihood  that  a given  set  of 
tests  include  the  crucial  points.  If  all  tests  might  succeed, 
yet  errors  rei*ainf  our  testing  scheme  is  on  shaky  ground. 


e A ISIS  : 515EL-S  Milt!  A»ie«2  §QSi  IS512 

Axions  and  test  cases  can  be  appended  to  a SIMPL-D  CLASS  as 
uefined  in  Section  1.  The  fora  is: 

I SIMPL-D  CLASS  definition 
AXIOMS 

• ** 

. algebraic  axioms  describing  the  abstraction 
TESTPOINTS 

. declaration  and  initialisation  of  test  values 
TESTSETS 

. sets  of  test  points  to  be  used  with  each  axioa 

START 

we  call  the  resulting  system  DAISTS  for  exactly  what  it  is:  £ata 
Abstraction  Implementation*  Specification*  and  Testing  System* 

In  the  AXIOMS  section  each  axiom  has  a name*  an  optional  free 
variable  list  containing  the  types  and  names  of  each  free 
variable  used  in  the  axiom  body*  a colon*  an  axiom  body*  and  a 
terminating  semicolon*  The  axiom  body  has  the  form: 

<left  side>  = <right  side> 

where  either  side  may  contain  references  to  free  variables 
and  operations*  In  addition*  the  <right  side>  may  contain  a 
conditional  expression  tike  that  of  ALGOL  60: 

IF  <boolean>  THEN  <exp>  ELSE  <exp> 

One  of  the  familiar  axioms  of  the  bounded  stack  CLASS 

appear  s as  : 

Pop2(Stack  S*  EltType  1): 

Pop ( Push ( S * I ) ) * IF  Dept  h ( S)  * Limit 

THEN  Pop ( S) 

ELSE  S; 

This  axiom  tells  us  that  the  result  of  popping  a Stack  S after 
pushing  a new  value  1 onto  S is  the  same  as  either: 
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1.  the  value  of  the  object  obtained  by  popping  S (If  S 
already  contained  the  naaiau*  nuaber  of  values  before  the  push, 
attempts  to  push  a new  value  on  s would  be  ignored. ),  or 

2.  the  value  of  the  original  Stack  S otherwise. 

The  TESTPOINTS  section  looks  like  a Sl*pL-D  procedure, 
complete  with  local  declarations  and  executable  statements.  This 
section  has  been  included  to  allow  users  to  build  objects  to  be 
referenced  in  the  TESTSfTS  section  of  the  program.  An  object 
that  is  expensive  to  construct  can  thus  be  used  in  testing 
several  axioms  without  repeating  its  construction.  For  example, 
a useful  point  for  testing  a bounded  Stack  might  be  obtained  as: 

Stack  ST 

ST  :=  Push ( Pu sh (Pus n ( N ew S t a c k , 1 ) , 2 ) » 3 ) 

The  TESTSETS  section  of  the  program  contains  a list  of  axiom 
names  with  values  to  be  substituted  for  the  free  variables  of  the 
axioms.  For  example,  a three-element  test  set  for  the  Pop2  axiom 

i s: 

Pop2:  (NewSt ac k .1  ) . (SI, 2).  (SI,  3); 

This  set  of  tests  and  the  Pop2  axiom  will  be  used  to  "exercise*' 
the  implementation.  First  with  hewStack  bound  to  S and  T bound 
to  1.  we  will  u$e  the  body  of  the  Pop?  axiom  as  a driver  program 
that  invokes  implementation  functions.  If  the  left  and  right 
sides  of  an  axiom  do  not  return  values  that  are  judged  to  be 
ejual  by  the  appropriate  implementation  function  (here, 
StackEqual),  a diagnostic  message  is  printed  indicating  that  the 
axiom  has  failed.  This  process  is  repeated  with  SI  (an  object 
initialized  in  the  TESTPOINTS  section)  bound  to  $ and  2 bound  to 
I,  and  finally  with  ST  bound  to  S and  3 bound  to  I. 

In  order  to  achieve  this  behavior,  we  compile  the  axioms  into 
procedures  and  the  test  sets  into  calls  on  the  appropriate 
procedures.  The  Pop2  axiom  becomes: 
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PROC  Pop2 (Stack  S.  € l tType  I > 

IF  .NOT.  StackEqual(Pop(Push(S,I) 
IF  Depth  (S)sLimit  THEN 


Depth (S ) 

THEN 

WRI TE  ('•**  aiio*  Pop2  felled  ***') 

END 


^pp(S)  ELSE  S) 


and  the  test  set  for  Pop2  Is  translated  Into  the  following  code: 


CALL  Pop2 (NewS t ack , 1 ) 

CALL  Pop2 ( Si , 2 ) 

CALL  Pop2(S2,3) 

The  following  program  is  the  bounded  stack  example  fro* 
Section  1 augmented  with  axioms  and  test  sets.  Rather  than 
repeat  the  original  CLASS  declaration  tor  the  bounded  stack  type, 
we  have  employed  the  SIMPL-D  USE  directive  which  obtains  the 
CLASS'S  representation  and  operation  interface  information  from 
the  file  appearing  as  its  arguement.  This  file  must  have  been 
previously  created  by  a separate  compilation  of  the  module 
containing  the  bounded  stack  declaration.  Me  have  reproduced  the 
interface  information  in  the  comments  following  the  USE 
directive.  Notice  that  the  axioms  are  parameterized  by  the  type 
EltType,  which  is  defined  by  macro  definitions  preceding  the 
axioms.  However,  the  test  sets  are  given  in  t*rms  of  integer 
values,  the  type  bound  to  EltType  during  this  compilation.  No 
test  sets  are  given  for  the  axioms  Emptyl,  Topi,  Popl,  and 
Depthl.  These  axioms  involve  no  free  variables;  the  single  calls 
to  test  them  are  generated  automatically. 

/♦  USE  'Stack'  ♦/ 


/* 

/* 

/* 

/* 

/* 

H 

/* 


for  Stack  x/ 


NT)  */ 


Stack  FUNC  Push (St  ack  , I 
Stack  FUNC  Pop  (St a ck  ) *7 
INT  FUNC  TopCStack)  «/ 

INT  FUNC  Empty (Stack ) */ 

INT  FUNC  StacxEqual (Stack , Stack) 


FUNC  StackEqual istac 
INT  FUNC  Dept  h (Stack  ) */ 
INT  FUNC  Limit  */ 


*/ 


DEFINE 


True  * '1'.  False  = 'O', 
EltType  « iNT * , Undefined  * 


'0' 
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AXIOMS  /*  the  "functional"  Model  */ 


Empty  1 : 

Emp t y (NewS t a ck  ) = True; 


£mpty2(Stack  S,  EltType  I): 

E np t y ( Push ( S * I > ) = False; 


Topi ; 

Top (NewStack  ) = Undefined; 


T op2 ( S t ac  k S.  EltType  I): 

Top ( Push (S » I ) ) = IF  Depth(S)  = Limit 

THEN  Top ( S ) 

ELSE  I; 


Pop  1 : 

Pop ( Ne wS t a c k ) = NewStack; 


Pop2 (Stack  S,  EltType  I): 

Pop (Push(Sfl))  = IF  Oepth(S)  * Limit 

THEN  Pop ( S ) 

ELSE  S; 


Oep  th 1 : 

Dept h ( NewS t a ck  ) * 0; 


Depth2(Stack  S#  EltType  1): 

Depth<Push IS »I>)  = IF  Depth(S)  * Limit 

THEN  Dept h ( S ) 

ELSE  DePth(S)  ♦ 1; 


EquatC: 

Stack Equa l (NewSt ack f NewStack  ) = True; 


EQualKStack  P.  Stack  Ot 
StackEqual(Push(Pyi 
IF  Depth  (P ) < 

THEN 

I F Degth(Q)  < Limit 
IF  I * J 

THEN  StackEqual (P*Q) 
ELSE  False 

ELSE  StackEqual(Push(P»I>*Q) 

ELSE 

IF  Depth(Q)  < Limit 

THEN  StackEquaMP,  Push(«,J)) 
ELSE  S t a ckEqua l ( P , Q ) ; 


Equal2(Stack  P, Stack  Q ) : 

Stack Equa l (P «Q>  = S t ac kEqua l (Q  , P ) ; 


Equal3(Stack  P.  EltType  I>: 

S tack Equa l ( Push  IP ( I ) v NewStac k > * False; 


EltType  It  EltType  J): 
) » (Push(Q, J))  * 

Limit 
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TESTPOINTS  /*  to  be  used  in  the  test  sets  */ 

Stack  SI,  S 2 
INT  I 

Si  : = Push( Push (Push (NewSt ac k ,1 > ,2 > ,3) 

§2  :=  SI 
1 :*  4 

WHILE  I <*  L 1 • 1 1 00 
S2  : = push  (s2,I) 

I :=  I ♦ 1 
END 


START 

The  very  first  running  version  of  DAISTS  uncovered  an  error 
in  the  iap leaentat ion  of  Depth.  The  Depthl  axioa  was  translated 

into: 

IF  .NOT.  ( Dept h (NevSt ack ) = 0) 

THfN 

WRITE('»*#  error  in  axioa  Depthl  ***  ) 

END 

Our  original  Depth  function  vas  iapleaented  as  follows: 

INT  FUNC  Depth (Stack  S> 

RETURN(S.StackTop) 

(compare  Section  1).  The  StackTop  coaponent  of  a Stack  object  is 
assigned  the  value  >1  in  NevStack  to  indicate  that  the  object  is 

a 

empty.  (The  index  range  of  SIPPL  arrays  is  0 • .upperbound-1 • ) 
Thus,  Depth(NevStack > returned  -1  and  the  aessage  that  the  test 
data  failed  the  Depthl  axioa  was  printed. 

The  axioas  and  tests  cannot  guarantee  that  the  lapleatntation 
is  without  errors.  Errors  in  the  iapleaentation  aay  interact  in 
ways  which  still  satisfy  the  axioas.  For  exaaple,  if  Push  siaply 


TESTSETS  /*  to  “test"  the  axioas  */ 

Eapty2:  (SI, 7),  (NevStack ,1 ) ; 

Top2 : {NevStack  ,3) , (S2,2);  ' , 

Pop2:  (NewS tack  ,1 ) . (si, 2).  (S2,3>; 
Dept  h2  : (NewS t ack  . 1 > , (SI, 2).  (S2,3>: 
Equa 1 1 : (SI, SI, 2,3),  (SI. $1,2. 2),  (S2 


Equa l 2 
Equa l 3 


: (NewStack ,1 ) , (51,2).  (S2,3): 

: (SI, SI, 2, 3),  (SI, 51, 2, 2),  (S$,S2,1,2), 

: (NevStack, 7),  (S2,c); 


(S2.S1); 
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updated  the  StackTop  component  of  Stack  objects  without  retaining 
any  values,  the  only  axiom  to  fail  would  be  Top2  since 
T op ( P u sh ( S i I ) ) t I*  Now,  if  the  equality  function  for  EltType 
objects  was  also  incorrect  (always  returning  true),  the  aiioas 
would  all  be  satisfied  by  a faulty  implementation.  However,  if 
we  require  the  user  to  supply  enough  test  data  to  cover  every 
part  of  his  axioms,  he  may  find  that  he  cannot  supply  test  data 
to  the  cquall  axiom  to  reach  the  ELSE  clause  guarded  by  the 

j 

c ond i 1 1 on  ; 

Oepth(P)  < Limit  & Depth(Q)  < Limit  & I t J 

because  I = J.  Preliminary  ideas  about  coverage  monitoring  are 
presented  in  the  next  section. 
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I 

J 

} 

* 

Issiica.  Siru£lu£il  taDiictiQU*  «cd  tsrifisicssi 

• 

In  conventional  program  testing*  specifications  enter  in  the 
form  of  an  "oracle***  a means  of  magically  obtaining  the  correct 
results  with  which  the  test  is  to  agree.  In  practice  this  oracle 
is  a human  being  examining  the  output*  perhaps  too  often  willing 
to  agree  with  the  program.  (This  position  can  be  justif ied--some 
programs  are  solving  problems  that  can  be  attacked  no  other  way.) 
It  is'crucial  to  distinguish  an  oracle  that  can  judge  the  output 
for  an*  input*  from  a "limited  oracle"--a  set  of  given  input* 
output  pairs  encoding  only  a part  of  the  complete  behavior.  The 
latter  can  be  obtained  by  physical  simulation  and  by  hand 
calculation*  but  when  structural  testing  criteria  are  used* 
inputs  are  generated  that  may  not  keep  within  a given  collection. 


Testing  based  on  pure  input-output  pairs  has  little  to 
recommend  it;  since  any  test  is  finite*  it  could  be  met  by  a 
program  written  as  a statement  covering  the  given  pairs*  and 

otherwise  entering  a never-ending  loop.  The  addition  of 
structural  test  criteria*  additional  constraints  on  the 
collection  of  tests*  has  its  origin  in  avoiding  such 
counterexamples.  The  simplest  structural  criterion  is  that  each 
and  every  statement  of  the  tested  program  must  be  executed  for 
some  input  among  the  tests.  If  the  every -statement  criterion  is 
met*  then  it  cannot  be  that  the  program  is  hiding  a special  block 
of  code  that  takes  some  unpleasant  action  outside  the  finite  test 
collection.  Put  the  other  way*  it  is  certainly  wise  to  have  used 
all  the  code  in  some  way;  entirely  untried  code  can  contain 
arbitrarily  nasty  bugs.  formally*  structural  criteria  are 
designed  to  lead  to  ££iilfeilit£  of  a test--the  property  that  if 
errors  are  not  exposed*  there  are  no  errors.  L*t  a program  P 
be  given  the  meaning  (function  computed)  CP)  by  its  semantic 
definition*  and  let  f be  the  function  that  the  program  ought  to 
compute  (according  to  the  idea  of  some  human  being).  Then  a 
collection  of  test  data  0 is  ££ij£fei£  is £ £ iff 


CP  3 1 = fl  “>  CP3  = f . 

D 0 

This  definition  (due  to  [Howden  1976])  Makes  an  exhaustive  test 
trivially  reliable.  Every  program  has  a finite  reliable  test* 
but  there  is  no  way  to  judge  mechanically  a given  program  P and 
test  data  P to  determine  if  D is  reliable  for  P [Howden* 
1976,  hamlet,  1977a].  By  st r engt hen i ng  the  specification  to 
include  more  Information  about  fegg  the  program  must  behave*  or  by 
restricting  the  set  of  errors  that  must  be  detected,  mechanically 
checkable  reliability  can  be  attained  [Hamlet  1978]. 

The  DA1STS  processor  described  in  Section  3 provides  a rich 
testing  vehicle.  The  dual  mach i n e-p r oc es s ab  le  texts  of  axioms 
and  implementing  code  can  make  do  without  an  oracle.  When  trying 
a test  point  in  an  axiom*  we  do  not  know  what  operation  values 
should  result,  but  we  do  know  a relationship  that  should  hold 
among  them.  The  virtue  in  this  form  of  oracular  information  is 
that  it  is  available  for  any  and  all  test  points  that  might  be 
tried,  not  only  those  of  a preselected  set.  The  drawbacks  of 
spurious  success  have  been  noted  in  Sections  2 and  3.  In  DAISTS, 
tests  can  be  required  to  satisfy  structural  criteria  not  only  on 
the  program  code*  but  on  the  axioms  as  well.  In  this  section  we 
explore  the  potential  of  tests  with  structural  constraints  for 
detecting  inconsistencies  between  abstractions  the  code  correctly 
implements,  and  abstractions  that  satisfy  the  axioms.  In  the 
process  we  also  hope  to  learn  about  the  relationship  of  code  and 
axioms  to  the  abstraction  the  programmer  had  in  mind. 

Section  2 describes  the  significance  of  a test  failure  in  an 
axiom  compiled  into  code:  either  the  implementation  or  the  axiom 
(or  both)  . is  inconsistent  with  the  intuitive  abstraction  desired. 
It  is  probably  easiest  for  a person  to  analyze  the  code  function- 
by-function,  and  turn  to  the  axiom  only  if  each  step  in  its 
extended  implementation  diagram  checks  out.  In  what  follows  it 
is  assumed  that  each  error  in  code  or  axiom  is  corrected  as 
discovered.  The  result  of  testing  is  then  a collection  of  points 
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f :r  which  the  axioms  dg  execute  successfully*  Structural 
criteria  are  now  introduced  to  enhance  the  significance  of  the 
successful  test  collection. 

for  conventional  program  code  there  are  path  and  expression 
structural  constraints,  cor  respond  ing  to  the  control/data 
dichotomy.  A combination  of  the  two  tan  be  reliable,  but  not 
within  a time  feasible  for  real  programs.  Hence,  a number  of 
ai proximations  to  the  impractical  exhaustive  constraints  exist, 
monitoring  a particular  constraint  can  be  accomplished  by  a run- 
time support  routine  in  DAISTS  (the  path  constraints  are 
particularly  easy  to  handle).  In  what  follows  we  concentrate  on 
the  significance  of  constraints,  not  on  details  of  approximations 
and  monitoring  algorithms,  which  are  straightforward.  The 
c :mp i t e r-ba sed  testing  approach  CHamlet,  1977b]  has  the  virtue 
that  all  testing  is  accomplished  by  a run-time  module,  in  which 
the  algorithms  are  written  in  SIHPL-D,  and  therefore  easy  to 
change  and  to  experiment  with.  We  therefore  expect  to  defer 
decisions  about  what  and  how  to  monitor  as  long  as  possible. 

Path  criteria  are  the  easier  to  understand.  All  possible 
inputs  to  a program  divide  into  eauivalence  classes  according  to 
which  control-flow  path  each  input  follows.  A given  test 
collection  meets  an  exhgustige  g^th  ggnjirginj  iff  it  includes 
one  member  from  each  such  equivalence  class.  The  unreliability 
of  path  testing  [Mo*den  1976]  results  iron  an  ir. proper  or 
insufficient  coverage  of  some  path-defined  class*  Approximations 
tc  the  exhaustive  path  constraint  are  necessary,  because  when 
code  contains  loops,  the  number  of  paths  may  be  unbounded.  The 
simplest  approximation  requires  each  statement  to  be  executed  for 
some  test  point . 

Within  axioms  compiled  into  code,  the  only  analog  of  path 
constraints  occurs  when  there  are  conditional  cases,  and  then 
exhaustive  path  testing  is  the  same  as  "branch  testing"-- 
requiring  that  both  alternatives  be  taken.  Except  for  this  case, 
the  test  points  necessarily  take  the  single  path  through  each 
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axiom  that  corresponds  to  moving  across  the  bottom  of  Its 
extended  implementation  diagram.  However*  It  may  be  helpful  to 
the  programmer  to  “cover"  one  axiom  at  a time*  and  observe  the 
path  coverage  that  results  within  the  1 ap leaen ta 1 1 on  procedures. 

Expression  constraints  on  code  have  a better  axloa  analog 
than  do  path  containts.  All  possible  Inputs  to  a prograa  are 
divided  Into  equivalence  classes  by  value  sequences  (histories) 
assigned  to  a single  expression  within  the  prograa.  A given  test 
collection  meets  an  e*hJuSli)fS  SuEESSilSD  £9Q2l£iiC£  ***  i* 
includes  one  member  from  each  such  class.  Expression  constraints 
are  less  used  in  practical  testing  because  they  are  harder  to 
app ro a ima t e * and  even  the  approximations  are  expensive  to 
monitor.  One  of  the  simplest  approximations  is  that  of 
forbidding  constant  subexpress ions--a  s«t  of  tests  is  lacking  if 
any  nonconstant  part  of  any  expression  has  exactly  the  sane  value 
history  for  all  test  points. 

Since  axioms  are  expressions*  they  are  covered  just  as  is 
code*  according  to  an  expression  constraint.  An  obvious 
interpretation  if  axioa  expressions  reaain  constant*  is  that 
(insofar  as  the  tests  can  determine)  the  trivial  abstraction  has 
been  specified.  Axiom  expression  coverage  has  sore  significance 
than  coverage  for  code,  just  because  there  are  few  asiom  “paths" 
to  consider. 

The  interplay  between  structural  constraints  for  axioas  and 
for  code  suggests  a testing  methodology  something  like  the 
following:  Begin  by  finding  test  points  that  cover  the  axioms* 

with  as  little  redundancy  as  possible.  The  deficiencies  of  such 
a test  collection  in  code  coverage  indicate  parts  of  the  code  to 
examine  for  errors  (usually  of  the  sort  that  the  correctly 
implemented  abstractions  are  too  complex).  If  the  code  proves  to 
be  correct  on  examination*  seek  additional  test  points  to  cover 
it*  and  examine  the  redundant  coverage  these  points  Introduce  in 
the  axioms*  suggesting  that  the  abstractions  satisfying  them  are 
too  simple. 
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5.  Sialyj  of  fiAJSIS 


work  is  proceeding  on  the  DA  1 STS  processor.  At  this  writing, 
the  processor  will  permit  users  to  supply  iaplementat ions, 
axioms,  and  test  points  and  will  “exercise"  the  implementation. 

In  the  next  stage  of  development,  we  plan  to  add  simple 
structural  testing  criteria  to  check  stateaent  coverage  and 
expression  variability. 
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